Assigning product and product module names
There is a convention whereby the framework assigns procedural objects you create to a directory structure corresponding to the product module names. Within the products for the Repository itself, a hyphen within a module name indicates the concatenation of a product and product module. For example, there is an RY product for objects that support Repository maintenance (the SDOs, dynamic windows and browsers, viewers, and so forth that make up the maintenance windows for the utilities under the Administration and Development menus, for example). Within the RY product, there are a number of different modules for different types of objects, for example, ry-app for AppServer-related procedures, ry-obj for general objects such as SDOs, ry-inc for include files, ry-uib for static container procedures, etc. This particular organization is done more by the type of object than its purpose, but any organization will do. The significance of the name is that procedures in the ry-app module are found in the ry\app directory relative to the top-level src directory for the framework. If this kind of organization is appropriate for you, then you can give your product modules names in this same way. In any case, you will specify the actual relative pathname for objects when you define the product module.
object_path field in the ryc_smartobject Repository table. There is no equivalent for dynamic objects.
In almost every screen in the Repository maintenance tools, you can select the Product Module from a drop-down list as a way of filtering objects when you are searching for something. Keep this in mind as you organize your application. Between the subdirectory structure for procedural objects, and the drop-down filtering for all kinds of objects, using product modules can help you locate and keep track of objects more efficiently.
Another important point to keep in mind is that you can define security structures, such as access restrictions on an action, data range or field, for a specific Product Module or for all Product Modules. Thus, you can easily restrict access, for example, to all Add functions within a product module for a particular user. This can be another effective use of the product module to organize your application.
|
To define products and product modules: |
- From the Administration window, select Application
Product Control. - Choose the Add button in the bottom toolbar to bring up the Product Maintenance window so that you can create a new product, as shown:
- In the Product Code field, enter a one-word name for the product.
- In the Product Description field, enter a longer description of the product.
- Choose Save.
The Product Control window appears with a list of all existing Products. Initially, the products defined are for the Repository itself, as shown:
The framework does not currently use the Product Installed and Number of Users fields. The intent of the Product Installed field is to adjust what application components such as menu structures are displayed to a user, depending on whether that product is installed at that user site. Likewise, the intent of the Number of Users field is to apply some sort of licensing restrictions to a site; counting users at this point is your responsibility if you want to make use of this field.
You should set Product Installed to Yes and leave the Number of Users at 0. However, these settings are stored as fields in the gsc_product table in the Repository database, and if you would like to make use of these fields as a control mechanism for your application, set these fields to values that are meaningful for you.